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REMARKS 

In response to the Office Action mailed December 21 , 2006, Applicants respectfully 
request reconsideration. To further the prosecution of this application, amendments have been 
made in the claims, and each of the rejections set forth in the Office Action has been carefully 
considered and is addressed below. The claims as presented are believed to be in condition for 
allowance. 

Claims 1-41 were previously pending in this application. Claims!, 15, 29 and 41 are 
amended herein. No claims have been added or canceled. As a result, claims 1-41 remain 
pending for examination, with claims 1,15 and 29 being independent. No new matter has been 
added. 

Telephone Interview With Examiners 

Applicants' representatives thank Examiners Debnath and Pich for the courtesies 
extended in granting and conducting a telephone interview on March 20, 2007. The substance of 
the interview is sunmiarized herein. 

During the interview, Applicants' representatives provided an overview of one 
embodiment of the invention, which is directed to facilitating the execution of context sharing 
applications in an environment with a less than fully-enabled context manager. 

By way of background, Applicants' representatives described context management 
systems in general. Specifically, Applicants' representatives explained that that in certain 
settings, users employ and provide input to multiple applications which relates to a cormnon set 
of entities, or "subjects." For example, in the healthcare field, a user may provide input relating 
to a particular patient to multiple applications (e.g., a clinical application, financial application, 
etc.). Before context management systems were developed, when a user switched from one 
patient to another, the user was forced to repeat the entry of data relating to the patient to each 
application. Context management systems enable multiple applications to share data relating to a 
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particular subject (e.g., a patient), such that the user need not re-enter data relating to the subject 
to each application, but need only switch to the patient within one application and have the 
context management system execute that change for all applications that share the patient 
subject. 

. Data describing one or more subjects commonly used and shared by multiple applications 
is referred to as a "context" shared by those applications. Although the patient subject is an 
illustrative example, applications may share context defined by one or more other subjects as 
well, or instead. For example, applications may share context defined by the user subject, so as 
to enable "single sign-on" capabilities wherein a user logs in to a single application and is 
automatically given access to other applications that share the user subject. Other subjects in the 
healthcare field include encounter, clinical provider, observation, insurer, etc. Other subjects, 
including subjects for fields other than healthcare, are possible. 

A context management system may include a context manager which manages context 
for multiple context participant applications (see, e.g., Applicants' specification at p.2, lines 23- 
24). Each of the applications includes programmed routines enabling communication with the 
context manager (p.3, lines 25-29). This communication occurs according to a context 
management specification (e.g., the CCOW standard, which defines processes for managing 
information on a given subject across a range of healthcare-related applications) (p.l, lines 23- 
28). When a user of one of the applications wishes to change the context (e.g., by changing the 
data for a subject, such as by switching firom one patient to another in the application), the 
application sends a request to the context manager (p.4, lines 3-7), which may change the context 
(p.4, line 8 - p.5, line 4). 

As explained during the interview, in some conmiercial environments, it may be 
advantageous to offer customers the option of purchasing a context management system which 
enables sharing of only a subset of the subjects defined by a particular context management 
specification (e.g., the CCOW standard) (p.7, lines 6-1 1). For example, some customers may 
wish to purchase a system which allows sharing of the user subject only (e.g., to enable single 
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sign-on capability) but not other subjects (p.7, lines 12-15). Other customers may wish to 
purchase a system that enables sharing of all subjects except for the user subject (e.g., patient, 
encounter, etc.), because they do not wish to pay more for single sign-on capability (p. 7, lines 
15-18). 

Applicants have appreciated that if the applications in a computing envirdnment are 
configured to share all subjects defined by a context management specification, but the context 
manager is not configured to enable sharing of all subjects, the applications could malfunction, 
because they are incapable of communicating with the context manager in the manner they 
expect (p. 8, lines 3-9). For example, an application configured to share all subjects might 
request that the context manager provide it with its privileges relating to the user subject (p.8, 
lines 21-26). If the context manager is not configured to enable sharing of the user subject (e.g., 
because the customer did not purchase single sign-on functionality), it may not provide an 
indication of privileges relating to the user subject to the application (p. 8, lines 21-26). This can 
create problems, because the application may expect to receive an indication of all relevant 
privileges, including those relating to the user subject (p.8, lines 26-28). When the application 
does not receive the indication, it may not function properly (e.g., it may not perceive itself as 
having the authority to allow a user to log in) (p. 8, line 28- p. 9, line 2). 

Accordingly, one embodiment of the invention provides techniques for managing context 
in an environment wherein the context manager is configured to not enables the sharing of all 
subjects defined by a context management specification (p. 7, lines 18-21). One embodiment 
provides an interface which enables applications to set information relating to an unshared 
subject (in the example immediately above, the user subject), but maintains information relating 
to the unshared subject separately for each application, so that the information is not shared by 
the applications (p. 10, lines 14-17). In this manner, the interface enables applications to 
continue to function property, but prevents sharing of tinshared subjects (p. 1 1, lines 4-6). 

One illustrative embodiment shown in FIG. 2 (a copy of which is attached hereto) was 
discussed during the interview. FIG. 2 depicts an environment wherein context manager 305 
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facilitates a sharing of context between applications 301 and 303. In particular, context manager 
305 enables the sharing of the user subject, but not the patient subject. Context manager 305 
provides an interface which allows applications 301 and 303 to set and get values for the patient 
subject, but maintains information relating to the patient subject separately for each application, 
so that the patient subject is not shared between the applications. Specifically, context manager 
305 maintains a first set of patient information 3 13a for application 301, and a second set of 
patient information 313b for application 303. When application 301 seeks to set the patient 
subject (as shown at 315), only portion 313a is updated, and when application 303 seeks to set 
the patient subject (as shown at 317), only portion 3 1 3b is updated. In this manner, separate 
information relating to the patient subject is maintained for applications 301 and 303, so that 
when an application communicates with the context manager to set the patient subject, it receives 
the response it expects, and continues to operate normally. 

Independent claims 1,15 and 29 are rejected under 35 U.S.C. § 102(b) as purportedly 
being anticipated by PCT application WOOO/59286 to Seliger et al. ("Seliger"). As discussed 
during the interview, Seliger is commonly assigned with the present application, so that 
Applicants were well aware of the teachings pf Seliger when drafting the claims, and believe the 
claims distinguish over Seliger. 

Each of independent claim 1,15 and 29 requires, inter alia, a plurality of applications 
each configured to share at least first and second subjects in a context, a context manager 
configured to enable the plurality of applications to share the first subject but not the second 
subject, and an interface between the context manager and the plurality of applications which 
enables each of the plurality of applications to set the second (i.e., unshared) subject. 

As discussed during the interview, Seliger does not disclose a context manager 
configured to enable a plurality of applications to share a first subject but not a second subject, 
but rather a context administrator for administering a context management system that may 
include one or more context managers (see, e.g., p. 9, lines 13-16 of Seliger). In this respect, 
Seliger explicitly states that the context administrator includes logic defining the overall 
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operation of the system, but the actual maintenance and switching of context is perfomied by the 
context manager (p. 12, lines 3-5). The context administrator configures the context manager(s) 
in the system and a definition for each subject (p. 9, lines 20-29). In configuring a subject 
definition, the context administrator may specify the subject's name, a list of applications which 
may transact in the subject, and whether the subject is secure (i.e., whether only certain 
applications may get the subject's data) (p.2, lines 23-30). The subject definition may also 
include a value for each application which is a function of the application's pass code, so that the 
identity of the application can be verified when the application attempts to transact in the subject 
(p.4, lines 26-28). 

The passages of Seliger cited in the Office Action as purportedly disclosing a context 
manager configured to share a first subject but not a second subject relate to capabilities of a 
context administrator, not a context manager. As discussed during the interview, embodiments 
of the invention are directed to solving the particular problem which arises when an application 
is configured to share a subject defined by a context management specification, but the context 
manager is not configured to do so. This problem is not discussed in Seliger, let alone a solution. 

The Examiners evidenced an appreciation for these points, and indicated they would 
reconsider the rejection after reviewing this response. 

Claim Objections 

Claim 41 is objected to under 37 C.F.R. §1. 75(c) as purportedly being of improper 
dependent form for failing to further limit the subject matter of a previous claim. Specifically, 
claim 41 depends on itself 

Claim 41 is amended herein to depend from claim 40. Applicants respectfully request 
withdrawal of the objection to claim 41. 
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Claim Rejections Under 35 U.S.C. $102 
Claims 1-41 are rejected under 35 U.S.C. §102(b) as purportedly being anticipated by 
Seliger. Applicants respectfully traverse this rejection, as each of claims 1^41 patentably 
distinguishes over Seliger. 

A. Claims 1-14 

As amended, claim 1 is directed to a method for use in a computer system comprising a 
plurality of applications each configured to share at least first and second subjects in a context 
and a context manager (CM) to manage context sharing between the plurality of applications, 
wherein the CM is configured to enable the plurality of applications to share the first subject but 
not the second subject. The method comprises acts of: (a) providing an interface between the 
CM and the plurality of applications that enables each of the plurality of applications to set the 
second subject; and (b) maintaining values for the second subject separately for the plurality of 
applications so that the second subject is not shared among the plurality of applications. 

As discussed below, Seliger fails to disclose or suggest several of the limitations recited 
by claim 1. 

1 . Seliger Fails To Disclose Or Suggest A Context Manager Configured To Enable 
A Pluralitv Of Applications To Share A First Subject But Not A Second Subject 

Claim 1 requires a context manager which is configured to enable a plurality of 
applications, each of which is configured to share at least first and second subjects in a context, 
to share the first subject but not the second subject. 

The Office Action contends that passages of Seliger at p.4, lines 11-13, and p. 2, lines 
27-28 satisfy this limitation. This contention is imsupported by the reference. 
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The cited passage on p.4 states that in a health care setting wherein a context 
management system has been implemented, a doctor who switches from a heart monitor 
application to a blood analysis application need not re-enter a patient ID. This passage thus 
refers to the general capability of context subject sharing by multiple applications. 

The cited passage on p.2 describes one aspect of a subject definition. Specifically, the 
cited passage discloses that a portion of the subject definition ("IsSecure") indicates that only 
applications specifically configured to be participants in a subject can get that subject's context 
data (p. 2, lines 27-28). The cited passage is part of a larger description of the subject definition, 
which Seliger discloses may specify the subject's name, a list of applications that can transact in 
the subject, and whether the subject is secure (p.2, lines 23-30). Seliger explicitly states that the 
context administrator configures the subject definition (p. 9, lines 20-29). Specifically, Seliger 
discloses that the context administrator defines configuration parameters which include the 
applications that may join a particular context (e.g., via the "IsSecure" parameter), and the 
subjects employed in the system (p.9, lines 25-29). Seliger also explicitly states that the context 
administrator includes logic defining the overall operation of the system, but that the actual 
maintenance and switching of context is performed by the context manager (p. 12, lines 3-5). 
Thus, the passage cited by the Office Action relates to the capabilities of a context administrator 
and the characteristics of a subject definition defined thereby, and not to a context manager. 
Seliger simply says nothing at all about a context manager configured to share a first subject but 
not a second subject, as recited by claim 1 . 

As discussed in the overview above, a context manager may be configured to not share a 
subset of subjects defined by a context management specification (e.g., the CCOW standard) to 
satisfy the needs of customers who wish to purchase a CM system that allows sharing of only 
certain subjects (e.g., the user subject, so as to enable single sign-on capability). The 
configuration of a context manager to not share subjects is simply unrelated to a subject 
definition defined by the context administrator. Indeed, the context manager may, for example, 
employ the same subject definition for communications with applications regarding a particular 
subject regardless of whether the subject is shared or unshared. 
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A context manager configured to not share a subset of subjects defined by a context 
management specification gives rise to a particular set of problems which Seliger simply does 
not contemplate. As discussed above, if applications are configured to share all subjects but the 
context manager is configured to not share certain subjects, one or more of the applications may 
be incapable of commimicating with the context manager in the manner they expect, which could 
lead to application malfunctions (Applicants' specification, p. 8, lines 3-9). In one example, 
when a context sharing application is initialized, it may seek to communicate with the context 
manager to get values for all subjects in the context (p. 8, lines 9-1 1). If the application is imable 
to get values for all subjects, it may assume that it is not being executed in a context management 
system, and not seek to share context with other applications, but rather execute in a stand alone 
way (p. 8, lines 11-14). In the particular example wherein a context manager is configured to not 
share the user subject (e.g., because the customer does not wish to pay for single sign-on 
capability), an application which communicates with the context manager to determine its 
privileges relating to the user subject may not receive back this indication (p. 8, lines 21-26). 
Because the application expects to receive back an indication of all privileges, including those 
relating to the user subject, it may not perceive itself as having the authority to allow a user to 
log in (p. 8, lines 26- p. 9, line 2). 

The passages cited by the Office Action describe capabilities of the context administrator 
and the characteristics of subject definitions defined thereby. Seliger does not disclose or 
suggest a context manager configured to enable a plurality of applications to share a first subject 
but not a second subject. 

2. Seliger Fails To Disclose Or Suggest An Interface, Between The Context 
Manager And The Plurality Of Applications, Which Enables Each Of The 
Applications To Set An Unshared Subject ; 

Claim 1 recites an interface between a context manager and the plurality of applications 
which enables each of the plurality of applications to set a second subject which the context 
manager does not enable the plurality of applications to share. 
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The Office Action contends that two passages of Seliger (at p. 6, lines 17-20 and p. 3, 
lines 14-16) satisfy the limitation of an interface, between the context manager and the plurality 
of applications, which enables each application to set an unshared subject. This contention is 
unsupported by the reference. 

In the passage on p. 6, Seliger discloses that, in general, a context manager may 
communicate with applications via an interface. 

The passage on p. 3 is part of a quote from the CM 1.1 standard relating to dependent 
subjects, wherein one subject is dependent on another, such that if the dependent subject's 
context is changed the subject's context data is cleared (p.3, lines 6-8). The cited passage 
indicates that applications may set context data items for one or more other subjects during a 
context change transaction wherein a dependent subject is changed. The remainder of the quote 
from the CM 1.1 standard refers to rules for enforcing semantic interdependencies between 
context subjects ^.3, line 19 - p.4, line 8). Thus, the cited passage specifically refers to rules for 
sharing subjects between applications, rather than to subjects which are unshared by applications, 
as the Office Action contends. 

Seliger does not disclose or suggest an interface which enables each of a plurality of 
applications to set a subject which a context ihanager does not enable the- plurality of 
applications to share. Indeed, Seliger specifically states that certain applications may not get 
context data relating to specific subjects, such as secure subjects, let alone set such subject data. 
Specifically, in one of the passages cited by the Office Action (i.e., p.2, lines 27-28), Seliger 
explicitly states that the "IsSecure" portion of the subject definition may define that certain 
applications are not allowed to get a particular subject's context data. Seliger simply fails to 
disclose or suggest an interface which enables each of a plurality of applications to set an 
unshared subject. 
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3. Conclusion 

In view of the foregoing, claim 1 patentably distinguishes over the prior art of record, 
such that the rejection of claim 1 under 35 U.S.C. § 102(b) as purportedly being anticipated by 
Seliger should be withdrawn. 

Claims 2-14 depend from claim 1 and are allowable for at least the same reasons. 

B. Claims 15-28 

Claim 15 recites at least one computer readable medium encoded with instructions which, 
when executed, form a method substantially similar to the method of claim 1 . For the reasons 
discussed above with reference to claim 1, claim 15 patentably distinguishes over Seliger, such 
that the rejection of claim 15 under 35 U.S.C. § 102(b) as purportedly being anticipated by 
Seliger should be withdrawn. 

Claims 16-28 depend from claim 15 and are allowable for at least the same reasons. 

C. Claims 29-41 

Claim 29 recites a context manager for use in a computer system comprising a plurality 
of applications each configured to share at least first and second subjects in a context. The 
context manager comprises at least one processor programmed to, inter alia, enable the plurality 
of applications to share a first subject but not a second subject, and provide an interface between 
the context manager and the plurality of applications that enables each of the plurality of 
applications to set the second subject. 

It should be appreciated from the discussion above relating to claim 1 that Seliger fails to 
satisfy the limitations of claim 29, such that the rejection of claim 29 under U.S.C. § 102(b) as 
purportedly being anticipated by Seliger should be withdrawn. 

Claims 30-41 depend from claim 29 and are allowable for at least the same reasons. 
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CONCLUSION 

A Notice of Allowance is respectfully requested. The Examiner is requested to call the 
undersigned at the telephone number listed below if this communication does not place the 
application in condition for allowance. 

If this response is not considered timely filed and if a request for an extension of time is 
otherwise absent, Applicant hereby requests any necessary extension of tinae. If there is a fee 
occasioned by this response, including an extension fee, that is not covered by an enclosed 
check, please charge any deficiency to Deposit Account No. 23/2825. 



Dated: 



RespectfiiUy submitted, 




RichardT. Giunta 

Registration No.: 36,149 

WOLF, GREENFIELD & SACKS, P.C. 

Federal Reserve Plaza 

600 Atlantic Avenue 

Boston, Massachusetts 02210-2206 

(617)646-8000 
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